home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d20
/
rec_110.arc
/
RECSYSOP.DOC
< prev
next >
Wrap
Text File
|
1991-09-10
|
50KB
|
1,157 lines
Remote Echo Control (REC)
Version 1.10
Live Public Release
For free distribution to whoever needs it
Sysop Documentation
Copyrighted (c) 1990, 1991 by Daniel S. Fitch
All Rights Reserved
LICENSING AGREEMENT AND DISCLAIMER
Remote Echo Control (REC) and its accompanying utilities are
copyrighted by Daniel S. Fitch, and all rights are reserved.
They are not to be decompiled, altered, or re-engineered in any
way. This includes any patches to the load modules, and removing
the copyright notice that is displayed when the programs are
executed. Changing the archive format is permitted.
As this software is copyrighted, I expect that no one will
try to take credit for the work that I have done. The software
is to be distributed free of charge, with the exception of a
nominal charge for postage or disk media. Charges incurred by
users of a Pay BBS are not included in this restriction, unless
the charge is tied explicitly to REC.
You use the software at your own risk. I will not be
responsible for any damages resulting from the use of REC,
including but not limited to software, hardware, outages, or
monetary. I have taken all reasonable steps to properly test
this software, and will take all reasonable steps to correcting
any problems discovered.
If you do not agree to these restrictions, then do NOT use
this software. Use of this software indicates that you agree to
these terms.
REGISTRATION
You are expected and required to register the software.
This way I know how many copies are in use, and whether I
should continue to maintain it. Registered users will get
first notice on updates, and ONLY registered users will be
allowed to be beta testers.
There is no charge for registration. REC and its
accompanying utilities are not crippleware. There is no change
in operation of the software by registering the software.
Registration takes only a simple net-mail message to Dan
Fitch on 1:104/435@FidoNet or 200:5000/211@MetroNet. Include
your name, date of software installation, where you got the
software, your return net-mail address, and the city/state
where your system resides. I will keep this information
confidential, and use it only for purposes of maintaining
REC.
TROUBLE REPORTS
No matter how much testing is done, any software is bound
to have glitches or bugs present. This includes the
documentation. Please feel free to report any problems via the
REC_SYSOP support echo, or via private net-mail. It is available
via the MetroNet distribution system, and can be received in
FidoNet via a gateway link. You may be asked to send your
configuration and echo control files to the author at the name
and address listed above for registration. Please be
sure to supply the include the following information:
Complete hardware description
Compete software description
Which release of REC you are running
Any program terminations messages
Copy of relevant portion of the log file
Complete copy of your configuration file
A short narrative of the problem
Anything else you think might be needed
A voice number to reach you if necessary
INTRODUCTION
Enough of the legal matters and on to the program!
Remote Echo Control (REC for short) is simply a zone-aware,
point-aware program written for echo hubs that allows your echo
nodes to remotely control which echos they receive from your
system. This is done with no manual intervention on your part.
Installation is quick, configuration is simple, and execution
is fast, and logging is complete.
I did say that this program is zone-aware, and with good
reason. While there are several similar programs already
available, I have not found one that will both recognize zones
and work in multiple zones at the same time. Such zone support
is required when you are an echo hub in a zone other than your
primary zone. It is also highly recommended if you are an echo
hub and your system has addresses in multiple zones.
It is fully compatible with the forms of point addressing
used by most echo mail processors. You can use the private net,
point reference, or a fully qualified address. If you are not
involved with point systems, don't worry about this. If you are
then please read the section on point systems.
REC is also Zmail compatible. In fact, I wrote REC to work
with Zmail specifically but be flexible enough to not be killed
by minor changes to Zmail or by use with other mail processors.
By default, an echo node can only request echos with a feed
in the same zone the the requesting echo node. This is fine for
the majority of those using this software, but it presents a
major hassle for gateway systems. Therefore, CrossZone
configuration statements can be used to allow certain echos to
cross certain zone boundries.
REC will work just fine if you are an echo hub and have
addresses in only 1 zone. However, I strongly encourage that
you do use that zone in all your addressing in REC. Network
addresses will default to zones or net not specified, but you
will have less to think about if you do not use the defaulting
procedure.
DEFINITION OF TERMS
Just so everyone is using the same terminology, I will
briefly describe the terms I will be using in this
documentation. This is not intended as a short course, but
rather as a translation.
ECHO - The actual message area that is passed from system
to system.
ECHO HUB - The system that sends echo mail to your system
for you to distribute.
ECHO NODE - The node receiving echo mail from your system.
LOCKOUT - Blocking an echo from receiving mail on an certain
echo. This could be needed for several reasons,
including Network Policy, local Net policy, or echo
moderator decree.
CROSSZONE - Allowing certain echo nodes to access echos from
zones other than there own. This is not very common,
and is subject to a variety of policies in all networks
involved. You have the capability, and the
responsibility.
USER INSTRUCTIONS
Included in the distribution archive is an file
called RECUSER.DOC, and it contains the instructions for your
echo nodes on how to use REC. I suggest that you read it
right now. It will be easier for you to setup and understand
how REC works if you now what your echos nodes will be trying to
do, and how they will go about doing it.
INSTALLATION
While you can place REC in any directory on your
system that you wish, I suggest that you place it in its own
directory. This will make program updates easier and keep your
hard disk somewhat more organized.
The first step is to un-archive the distribution file
into the directory that you wish to use. The original
distribution file contains the following files:
REC.EXE - The main program
REC.CFG - A sample configuration file
RECSYSOP.DOC - Sysop documentation
RECUSER.DOC - User documentation
HISTORY.DOC - Revision History
NOTIFY.HDR - A sample notify message header
REPLY.HDR - A sample reply message header
The distribution file also contains a few little utility
programs that you may find useful. They were written for the
sysop of an echo hub, and are part of the REC package.
Consider them a bonus. These utility programs are listed
below and explained later in this documentation:
AREALIST.EXE - Alphabetical listing of echos
AREARPT.EXE - Echo Distribution Report
ECHOSOUT.EXE - Outbound echo mail tracker
READMSG.EXE - Formatted Display of .MSG file
To put REC in your batch files may require a bit of re-
working of your inbound mail processing. Two rules must be
followed exactly: 1) always process net-mail before ANY echo
mail, and 2) always run REC before you import the mail into your
message base.
A typical scenario would be similar to this sequence of
events. First, you process all net-mail packets and create
.MSG files, which are placed in your mail directory. Second,
you run REC to process any messages for REC. Third you run
your net-mail importer to import any remaining .MSG files into
your message base. Lastly, if any .MSG files remain in the mail
directory, run your net-mail bundler to make packets out of the
.MSG files.
This scenario will be to be done whether you are
processing non-compressed or compressed mail. This will
ensure that all echo mail changes are complete before you
processes any new echo mail.
REC is now on your BBS, and ready to be
configured. Coincidentally, Configuration is the next topic to be
discussed.
CONFIGURATION
The configuration file for REC is a standard ASCII file
that you can edit with any ASCII or Text editor. The example
is broken down into 6 sections, but the actual order you use is
up to you.
Certain entries are required, other entries must occur at
least once, and some entries are optional. The entire
configuration will be verified at the start of each run of REC,
which only takes a second or two. The entries are case-
insensitive, and the keywords must be followed by a single
space. If an entry can have more than one field after it, these
fields must be separated with a single comma. With the exception
of SystemName and SysopName, any spaces in the field must be
typed as an underscore ("_"). The program will replace them
with spaces when the configuration file is processed.
Each of the entries are described below in alphabetical
order. They appear in "logical" groups in the sample REC.CFG
file. For examples, please refer to the sample configuration
file found in the distribution file REC.CFG.
Address (MINIMUM 1)- This is a list of all the addresses
that your system is known as. This list should
include every address that your system uses to pass
echo mail in areas that you want to control with
REC. If you have addresses that you do NOT use for
echo mail traffic, do NOT list them here. At best they
will do nothing, at worst you will get wrong addresses
on your outbound mail. You may specify up to 10
Addresses, and the first address must be your
primary address. The should be in the same order as
your front-end mailer software.
EchoControlFile (REQUIRED) - This is the complete path and
name of the file that controls how the echos are
distributed. Only one file can be specified and
must be in the format shown below. All fields are
separate by at least one space. All fields are
required except the receiving addresses.
{location} {echo tag} {main feed} [receiving addresses]
Location - Can be any value desired, such as a
directory name, board number, or Pass Through
indicator. No spaces are allowed in this field.
Echo Tag - The name of the echo area.
Main Feed - Your echo hub's address for that echo
Receiving Addresses (optional) - The addresses that
your send this echo to. This should be compatible
with nearly all echo mail processors. If it is
not compatible with your mail processor, get in
touch with me so I accommodate your needs.
EchoHub - This is the definition of your echo hubs, which
are your primary echo feeds. This statement is not
really required, but omitting it does take away some of
the more useful features of REC. An entry is needed
for any echo hub which you want to use automatic
forwarding, which will be described in the REC
Processing Section. The format is shown and described
below.
EchoHub {address},{send to},{subject}[,type}
Address - The network address of your echo hub.
Send To - The name that you want to address the message
to.
Subject - The text that you want to see on the message
subject line.
Type (option) - Two possible values can be placed here:
"REC" or "Areafix". If the field is omitted or
has any other value, it will be ignored. This
field is used only with Automatic Forwarding, and
is described in the REC Processing Section. The
default value will have messages addressed for a
human being to read.
EchoNode (MINIMUM 1)- This is the definition of each of your
echo nodes that you want to use REC with. You can
have nodes listed in your Echo Control File that are
not listed as an Echo Node, but only nodes listed as
Echo Nodes will be allowed to use REC. The only
optional fields are the 3 sysop names. The format is
described below:
EchoNode {address},{echo
hub},{password},{security}[,sysop name 1][,sysop
name 2][,sysop name 3]
Address - The net address of the echo node being
defined.
Echo Hub (Optional) - The net address of the echo hub
that any forwarding echo requests should be sent
to. This address must be defined with an Echo Hub
entry.
Password - This the password that your echo node must
use to get access to REC processing.
Security - This is the numeric security level (0 -
32767) that the echo node has. The echo node will
only be able to request echos with an security
level equal to or below its own security level.
Sysop Name 1-3 - You have the option of restricting REC
access by name. The password checking is still
active. If at least 1 name is specified, then the
sender of the REC message must be listed here for
REC to accept the message. If no names are
specified, then the message will be accepted by
REC no matter who the sender is. These fields are
also used by some other parts of REC, so I
strongly encourage to specify at least one name
for each echo node.
MailDirectory - This is the directory that you will place
net mail messages. REC requires that incoming net-mail
and out-going net-mail be placed in the same
directory. These messages must be in MSG format per
Fidonet Technical Standard #001 (FTS-001).
SystemName - This is the name of your system, and will be
placed on generated messages to your echo nodes and
your own echo hubs.
SysopName - This is your name, and will be placed on
generated messages to your echo nodes and your own echo
hubs.
Below are all of the optional statements that can be used:
AccessName - This is the name that you want your echo nodes
to use when they sent a message to REC.
If not specified, this entry will default to "Remote
Control".
CrossZone - This command will permit echos to cross the zone
boundry as long as the requesting echo node has at
least the minimum security stated in this statement.
The two flavor parts are optional and is discussed in
the CrossZone section. The maximum number of
statements is determined by how much RAM you have
available. The format is shown below:
CrossZone {from zone},{to zone},{security}[,[node
flavor,] [zone flavor]]
Lockout - This allows you to specifically deny access to
an echo by a particular node, with a maximum of 50.
No validity checking is perform on either the echo
tag or the address. The maximum number of statements
is determined by how much RAM you have available.The
format is shown below:
Lockout {echo tag},{address}
NotifyHeader - This does the same thing as ReplyHeader,
except that it is used for any notification messages
created by using the "/N" command line parm.
PassThrough - This allows you to specify the board that will
designate a pass-through echo. The default value is
"P".
ReplyHeader - This allows you to specify a "canned message"
to be put on all replies created by REC. It only needs
to be in straight ASCII text format, with NO ANSI
characters.
Secure - This allows you to specify a security level on
individual echos. The security level of an echo will
default to 0 unless it is specified here. Valid
security levels range from 0 to 32767. No checking
is performed to ensure the echo tag exists on the echo
control file. The maximum number of statements is
determined by how much RAM you have available. The
format is shown below:
Secure {echo tag},{security level}
SortBoard - This will make REC sort the echo control file by
echo board number. It has the same sectional sorting
capability as SortName. If two echo areas have the
same board, then REC will automatically use a secondary
sort key of echo tag.
SortName - This will make REC sort the echo control file by
echo tag. All sorting is done between comment lines.
In other words, if you use comments to break you echo
control file in a section for non-echo areas, general
echos, and private echos, all sorting will occur within
the individual sections. The sections will NOT be
merged.
StatusReport - This statment will cause REC to create and
send to the Sysop a net-mail message. This message
will detail out the status of you echo control file and
well as your echo nodes and echo hubs. This report is
described in detail in a later section.
ADDRESS DEFAULTING
The addresses that you specify will default in 3 different
ways. This defaulting allows REC to determine address
information if a piece is missing. I strongly urge you to
specify the complete zone, net, and node for all addresses in the
configuration file, and on all echo feeds in the echo area
control file.
The first Address statement you specify will default
using the address of 0:0/-1. Validation checks will be
performed to make sure that the address does not have a negative
number for any field.
Additional Address statements, Echo Hubs, Echo Nodes,
Security, and Lockouts will all default using the first Address
statement. You can see why it is important to have your primary
address listed first. If you do not follow this rule, your
mail will end up going to the wrong zones.
Addresses in the echo control file default using 2
rules. The Main Feed of the echo defaults to the first
Address statement in the Configuration file. The first
Receiving Address will default to the Main Feed, and all other
Receiving Addresses will default to the previous address
listed. Please examine the example below for an
illustration, and assume that the first Address statement
in the configuration file is for 1:104/435:
P SYSOP 1:104/1 200 303/202 204 205 3:100/1 110/50
The main feed will be 1:104/1. The complete receiving
address will be 1:104/200, 1:303/202, 1:303/204, 1:303/205,
3:100/1, and 3:110/50. The simply the echo control file,
REC will sort the receiving address in ascending order after
processing, and write them back out in the "short form" shown
above. Please note that since the complete address (including
zone) was specified for the main feed, no defaulting was needed
from the first Address statement. This is the safest way to
proceed, and I highly recommend it.
REC PROCESSING
Processing occurs is several steps, and is build on the
assumption that only one REC message will be processed per
run. This is NOT a limitation, but an observation from my own
system. If you process net- mail immediately after receiving it,
you are not very likely to process more than 1 message (unless
the echo node sent more than one message at a time). If you save
up net-mail until a speicific time and than process them all at
once, you will be more likely to processed several REC messages
at one time.
REC will process the configuration file and terminate if
there are any errors. If there are any .MSG files to process, it
will load the echo control file in to dynamic memory and process
the .MSG files. The echo control file will also be loaded if
batch mode is being used.
All batch commands will be processed before any .MSG files
are processed.
REC will scan the specified message directory and find all
.MSG file regardless of how the may be numbered. This is done to
allow processing with Gateway Systems, which are the main
exception to the observation shown above.
After all processing is completed, all replies will be
created. Then any file sorting (if any desired) will be done,
and lastly the echo control file will be written out to disk.
REC does not set any ERRORLEVEL's when it exits. If any are
needed please let me know, and I will get them added. So far I
have not seen or heard of any need for them. I may be wrong
about this, so let me know if I am.
AUTOMATIC FORWARDING
I have mentioned Automatic Forwarding a few times, so now
I will explain this neat little feature. You don't have to be an
echo hub for long before one of your echo nodes asks for an
echo that you are not receiving from your own echo feed.
This feature will allow you automatically pass on a request
to your own echo feed to start the echo. All that you have to
do is specify an Echo Hub address on the Echo Node statement for
each system that you want to use automatic forwarding. The
address on the Echo Node statement much match the address of one
of the Echo Hub statements.
When an echo node requests an echo that is not found in
the echo control file, the list of Echo Hubs is searched for a
match on the echo hub address found on the echo node statement.
If a match is found, a message is sent to the echo hub requesting
that the echo be activated. The fact that the echo request
was forwarded is noted on the reply message to the echo node
and the log file. If a matching address is not found or an
echo hub address is not specified on the echo node statement, an
appropriate message is noted in the reply and on the Log File.
This Automatic message can be sent to either a human or
another automatic echo control system, and this is controlled by
the Type field entered on the Echo Hub. At this point, REC
can send messages to another REC (of course) or Areafix. There
is only 1 difference between a message sent to a human or an
automated system. A message to a human will have a short blurb
at the beginning of the message asking to have the listed echos
activated. Both types of messages will have a tear line ("---
") followed by a short line informing the recipient that the
message was created automatically by REC.
The receiving address, receiving name, and subject
line are all populated from the Echo Hub entry. To have a
message to an AreaFix program, put "Areafix" (of whatever your
echo feed is using) as the Echo Hub's send-to field and the
password on the subject field. Remember you have to specify the
class as either AreaFix or REC to either of those programs. It
can't really be much easier.
CROSS-ZONE ECHOS
Allowing echos to cross zones was added for those gateway
systems that do this regulary. There are policy rules and
guidelines that must be adhered to when echos start crossing
zones, and I have no intention of addressing them here. REC will
assume that you know what you are doing if you employ this
feature.
The Cross Zone statement was described in the configuration
section. Here are a few tips for easy use of the Cross Zone
feature. First off, don't use it unless you need to use it.
Beyond that, set the security for crossing zones above that of
what you normally assign to echo nodes that do NOT cross zones.
If you have any echos that should not cross zones, set their
security higher than any of the Cross Zone statements.
A word about Cross Zone and Automatic Forwarding: An echo
node cannot have forwarding for multiple echo hubs. If you have
a system in a zone that is getting echos from more than one zone,
you will have to either disable automatic forwarding for that
echo node (by not specifying an echo hub address on the Echo Node
statement), or allowing automatic forwarding for only one of
those zones. I realize that this could cause some problems for
any gateways that cross several zones. If it does, please let me
know and we can discuss a better solution.
When echos cross-zone using this feature you can force Zmail
flavors on either the echo node, or the echo feed. This is
mostly used when running a gateway system. The first flavor code
will be put on the echo node requesting the echo. The second
flavor code will be put on the echo area's feed. You can use
either, both, or neither. Please look at the examples shown
below:
CrossZone 8,1,3000
CrossZone 8,1,3000,H
CrossZone 8,1,3000,,*
CrossZone 8,1,3000,H,*
The first example will allow an echo node in Zone 8 to
access an echo from Zone 1, providing that the echo node has at
least a security of 3000, and the echo has a security of less
than or equal the echo node security.
The second example does the same as the first, but will
force the "H" flavor code (for "Hold") on to the echo node.
The third example does the same as the first, but will force
the echo area feed to have "*" flavor code, which will have Zmail
leave these messages as *.MSG files. Do notice that there are
two commas between the security and the Feed Flavor code. That
is not a typo, but a requirement.
The fourth example will do all of the above with just one
statement.
For more information on Zmail Flavors, see the next section.
ZMAIL FLAVORS
Zmail Mail Processor (Copyrighted by ZZYZX) allows special
processing of the outbound flavors for your echo mail. You can
have the mail marked Crash, Hold, Normal, or allow it to default.
You can also have the echo mail not bundled but left as .MSG
files in your mail directory for another program to work on. The
actual rules and use of these options are left up to the Zmail
documentation.
However, they are completely supported by REC. Any
character other than a number, color (:), slash (/), or period
(.) is consider a special processing flag (or flavor code). You
can up to 10 symbols on a single address, and they can be put on
any address you need to. They also can be used with the FLAVOR
batch command and the CROSSZONE configuration statement.
Some default logic is imposed with these flavor commands.
If you put any flavor on an echo for an echo node, it will stay
there until you remove or change it. If it has no flavor when
the echo node is added to the echo (via a message or batch), the
flavor codes will be taken from the following places in this
order:
Batch Command Line
Cross Zone Statement
Echo Node or Echo Hub Statement
If you wish to have all the echo mail for a certain echo
node to have a certain flavor, just add that flavor to the
address part of the Echo Node statement. Every time that echo
node adds an echo, the flavor on the Echo Node statment will be
used. This works for Echo Hubs as well as Echo Nodes.
BATCH MODE
There will be times that is will be easier and faster for
you to submit an update to REC than to wait for the echo node
to send mail. Batch mode allows you to do this with a simple
text file and a command line parameter.
Batch mode is optional for the Sysop. You may feel it
faster and/or easier to make the change directly to the echo
control file yourself. However, batch mode is reported in the
log file which provides an audit trail. It can also be used to
perform certain updates at a particular time such as nightly
maintenance.
Perhaps it single greatest advantage is in transferring an
echo node from from echo hub to another. You could just setup an
event to run REC with your special batch command file at a
particular time, and let REC make the necessary changes while you
are sleeping comfortably.
To use batch mode, first you create a simple text file
with any text editor. If you create the batch command file
with the name BATCH.REC in the same directory as REC, it will
automatically be run with the next run of REC. In this text file
you just list the commands you want to execute with any needed
parameters. The complete list of available commands is shown
below:
Add - This command allows you to add an echo node to an echo
tag.
ADD {tag},{echo node}
Remove - This command allows you to remove and echo node
from the distribution of an echo. The special tag for
all tags can be used (see below).
REMOVE {tag},{echo node}
Create - This command allows you to create a new echo in the
echo control file. To add echo nodes to this echo, you
would need to use an "Add" command, which would have to
be coded after this statement.
CREATE {tag},{board,{feed}
Drop - This command allows you to remove an entire echo from
your echo control file. It is completly deleted from
the file.
DROP {tag}
Flavor - This command allows you to set flavor to an echo
for a particular echo node. Any flavor specified on
the address directly will be ignored. The flavor must
be placed after the echo node. To remove all flavor
from the tag and echo node, use the special flavor of
"*_NONE_*". The special for all tags can be used (see
below).
FLAVOR {tag},{echo node},{flavor}
Board - This command allows you to change the board of an
echo. You must specify the tag and the new board
value.
BOARD {tag},{board}
Tag - This command allows you to change an echo tag. You
must specify the current tag value, and the new value
you wish to use.
TAG {current tag},{new tag}
Feed - This command allows you to change the feed for an
echo.
FEED {tag},{new feed}
There is a special tag name that will cause the command to
work on any echo tag. This can only be used on Remove and
Flavor, for obvious reasons. The special tag value is
"*_ALL_TAGS_*" and should be typed in all uppercase.
Secondly, you execute REC with a command-line parm of /B
followed immediately by the filename of the text file you
just created. An example would be nice, and it follows below:
REC /Bmyfile.txt
In the above example, the file named "myfile.txt" will be
read and processed as a batch file. If the filename cannot be
found, an error message is displayed and logged. The batch
file is processed first, and the commands are processed in the
exact same way as if they came in from a net-mail message.
NOTIFY MODE
This is a quick and simple way to let your echo nodes what
echos they are receiving. This helps to make sure that your
echo node is getting only the echos desired, and all the
echos desired. During this Notify Mode, REC will still process
any batch command files and inbound messages addressed to REC.
Most often, you would use this mode once a week in a maintenance
mode. An example is shown below:
REC /N
This above example show the command line parm of "/N".
This forces batch notify mode, and will send an Active Echo
Report to every Echo Node listed in the configuration file, and
only to those addresses. If desired, you can have REC create a
sysop's status report during notify mode. This report is
described next.
STATUS REPORT
The Status Report is can be generated by two different
means. If the StatusReport configuration option is used, the
report will generated when REC is run in Notify Mode (/N
parameter, see previous section). It can also be generated by
running REC is Report Mode (/R parameter. While running in
report mode, REC will still process any batch command files or
inbound messages. An example is shown below:
REC /R
The status report is sent as net-mail to the address shown
in the first Address configuration statement, and address to the
name listed in the Sysop configuration statement. This report is
broken down into 4 major sections consisting of 3 summaries and a
dead-end echo listing.
The first summary is a summary of how many echos you have
listed in your echo control file. A "Local Area" is not really
an echo area, but is listed in the echo control file as required
for an off-line message base reader such as QMX or RaQSeX. An
"Imported Area" is an echo area that is imported into your local
message base, essentially not a pass-through echo. A "Pass-
Through Area" is an echo area that you get from one of your echo
hubs and pass on, but do not import into your own message base.
A "Dead-End Area" is an echo that area that your get from one of
your echo hubs, don't import, and don't pass on. Usually you
would want to stop these since they take up time and disk space
for no gain.
The second summary is an Echo Hub summary. It lists each of
your echo hubs and how many echos are feed from that source. It
ONLY reports on the echo hubs you have listed in your
configuration file.
The third summary is an Echo Node sumamry. It lists eacho
of your echo nodes and how many echos they are receiving. It
ONLY reports on the echo nodes you have listed in your
configuration file.
The last piece of the report does not always show up. It is
the listing of each dead-end echo and its feed. This would allow
you to issue cancel requests to the appropriate feed for the
appropriate echos.
You should realize that while the Echo Area Summary reports
on every echo in your echo control file, the Echo Hub and Echo
Node summaries do not. The total number of echos reported in the
Echo Hub summary will equal the total number of echo areas ONLY
if every one of your echo mail feeds are listed as an echo hub in
your configuration file.
POINT SYSTEMS
Point Systems are also called Private Nets or Point Nets.
In its simplest form, a point system is not much more than a
private network of BBS's. It is a fact, however, that humans
have become very good at making simple things complicated.
The major difference is that point systems don't appear in
the nationally distributed nodelist. The Boss Node of a point
system is basically the door by which it dependent points talk to
the rest of the world. All other BBS's just send the mail to the
Boss Node, and the Boss node passes on the mail to the individual
point systems. The point systems send all their mail to the Boss
Node, which then passes that mail on the to the rest of BBS
world.
As far as echo mail is concerned, you are just passing it
along like echo mail to any other BBS. Net mail takes a little
more work, but there are a couple of different ways to handle
that, all of which are beyond the scope of this documentation.
The addressing of a point system of perhaps the most
confusing part. There are 3 main ways to address a point system:
private net, point reference, or the complete full address. Take
my own system, for example. My FidoNet address is 1:104/435, and
my private net (or point net) is 30527. I could address my fifth
point (or private BBS) is any of these ways:
1:30527/5 (called private net)
1:104/435.5 (called a point reference)
1:104/435.30527/5 (the complete or "long hand" style)
The second style, or point reference, is all that the rest
of the BBS world would need to know to get a net-mail message to
one of my points. Echo mail is passed down via the echo control
file, just like it would be to any other BBS. Now for the
specifics of how REC handles point systems.
REC will (of course) accept any of these 3 formats of
addressing a point system. The important point to remember is
this: However you list the point system's address in the Echo
Node definition, is how it will show up in the echo control file.
Point systems will NOT be shown using the so called "short hand"
for addressing. This is illustrated next.
Assume that I receive the echo tag ABC from my local NEC,
and I pass it off to two other systems (210 & 550) and two of own
point systems ( 5 & 15). Here's what you would see in the echo
control file if I used point referencing for my points:
P ABC 1:104/1 210 435.5 435.15 550
If the second point listed (435.15) was only shown as "15",
it would actually be sent to 104/15 instead of my point. If I
used complete addressing, the same line would like this:
P ABC 1:104/1 210 435.30527/5 435.30527/15 550
The same line would like this if I used private net
addressing:
P ABC 1:104/1 210 550 30527/5 15
As you may have noticed, the private net addressing looks
just like address for net 104, except that the net number is 5
digits long instead of 3.
It is your preference as to which method you want to use.
What you should remember is this: If you use the PrivateNet
addressing style, your mail processor will NOT strip the Private
Net address from the seen-by and path lines. This may be against
the policy of either your Net or FidoNet.
Here is a very important tip to make your point systems
easier to manage: Be consistent. That may sound meaningless, but
if you are consistent then you have less confusion later on. It
does require some small amount of extra thought up front, but it
will be well worth it.
All replies and notifies are sent directly to the point
address, if the private net is known. If the private net is not
know, than it will be sent out as regular net mail, and you will
be expect to have some external program, such as REMAPPER to map
it to the correct private net.
If you use Private Net addressing (like 30527/5), you will
have absolutely no problems. If you use complete addressing
(like 1:104/435.30527/5), then you have fewer problems. If you
use Point Reference, you will have to be careful about re-mapping
both before and after REC is run, unless you put the private net
number in the appropriate address statement.
If I had an Address statement of 1:104/435.30527/0 and an
Echo Node address of 1:104/435.5, than any replies and notifies
would be sent to 30527/5 for that echo node ONLY!! Now that
brings up a nice little feature of REC. If you specify a private
net address on your Address statement, the private net will only
be used when sending the message TO one your points. See the
example below:
Address 1:104/435.30527/0
EchoNode 104/210,,Test1,100,First_Joker
EchoNode 435.5,,Test2,100,Second_Joker
All notifies and replies will be sent to First Joker on
104/210, or to Second Joker on 30527/5. This type of setup gives
you maximum flexibility to do this in which ever manner you want.
Just be consistent so you don't start to confuse yourself.
If you want a recommendation from the author (ie. me!), I
suggest that you use Point Reference addressing. This way the
your point appears no different than your own system to the
outside world. Also, REC will do the reply and notify address
mapping for you. Below is my recommendation in an example:
Address 1:104/435.30527/0
EchoNode 104/210,,Test1,100,First_Joker
EchoNode 435.5,,Test2,100,Second_Joker
ERRORS/MESSAGE PROCESSING
REC can return many different messages, and not all of
them are errors. In this section, I will list all of the error
conditions, and where they are reported. Everyone of these
errors/messages will be sent to the log file and the display
screen. I will not be covering the configuration errors, since
they are well detailed by the program error message if any should
be encountered.
First I will cover those messages that can be produced by a
message sent to REC from an echo node:
'Not found or processed': The command was not processed by
REC due to an error condition. You should not see this
message, but it was added to cover all possible logic
flaws in the program where a message command might be
skipped.
'Added': The echo was activated for the echo node.
'Already active': 'The echo was already active for that that
echo node.
'Insufficient security': The echo node lacked sufficient
security level to access that echo.
'Locked out': The echo node has been locked out of that echo
via the Lockout statement in the configuration.
'Zone-crossing restricted': That echo node is not allowed
this echo since the echo would be crossing a zone. If
a CrossZone statement was involved, it was because the
security of the echo node was less than the minimum
specified on the CrossZone statement.
'Forwarded': The echo was activated for the echo node and
forwarded to the echo hub.
'Not active': The echo node was not receiving the specified
echo so it could not be removed.
'Removed': The echo node was removed from the echo.
'Invalid report code': A report was requested, but the
report code was not one recognized by REC.
'Active echo report generated': This report was created.
'Available echo report generated': This report was created.
'Not found or forwarded': The echo did not exist and could
not be forwarded.
Listed next are the error messages that can be generated by
a batch command:
'Not Processed': This is the same as the one above.
'Processed': The command was processed correclty.
'Tag not found': The echo requested was not found.
'Node not found': The node request was not found.
'Tag already exists': A tag could not be created because
that tag was already being used by an existing echo.
'Node already active': The node was already active for the
echo.
'Invalid Command': Either the command was unknown or one or
more of the parameters were missing.
BONUS UTILITIES
As a free bonus, I have included a few simple little
utility programs that I find useful on my system. The command
syntax can by found by simply executing the program without
any command line parameters. I will give the syntax here as
well, along with a short description of what the program does.
AreaList - This program takes an echo control file and
produces a 3 column, alphabetically sorted, listing
of all echo tags found. No consideration is given
for separating by zones.
AREALIST {echo control file} {list filename}
AreaRpt - This program will produce a report from your
echo control file. The report is a listing of every
system found, and which echos that system is receiving
from you. Is is sorted alphabetically in a 3-column
format.
AREARPT {echo control file} {report name}
ReadMsg - This is a quick and dirty public domain
utility that basically displays the formatted contents
of a .MSG file.
READMSG {msg filename}
EchosOut - This program is designed to be put right in
the REC directory. It keeps track of how much echo
mail you send out. You should run it immediately
after you process any received echo mail, and after
you process any echo mail generated on your
system. It reads the outbound directory given,
updates a small tracking file called ECHOSOUT.TRK, and
writes out a sorted report. The tracking file
will be created/update in the current directory.
This report lists for each system found the system
address (with out zone) and the total daily volume in
Kybtes for the last 7 days. A Zone total and Run Total
are also generated.
You should note a few things. Always run the program
from the same directory, so it can always use the
same tracking file. To reset the report, just
delete the tracking file. Make sure the address on
the command line parm is your PRIMARY address but
do NOT give the zone. Only specify the outbound
directory for your primary zone, meaning without an
extension. The program will automatically check for
the other directories.
The program only takes a few seconds to run, and it
real useful watching how much echo mail your system in
handling.
ECHOSOUT {outbound directory} {net/node} {report file}
ECHOSOUT m:\out 104/435 volume.txt
CONCLUSION
Well, that's about all I have to say about REC and the
bonus utilities. If you have any questions, feel free to contact
me via net-mail to 1:104/435@FidoNet or 200:5000/211@MetroNet.
Send the message to Dan Fitch, or to Sysop.
There is a support echo on the FidoNet backbone. The echo
tag is called REC_SYSOP, and I encourage you use this echo. If
you cannot get access to that echo, feel free to contact me via
the ZZYZX software support echo. I have Claude Warren's (the
moderator) permission to use the echo for that purpose.
I have several plans in mind for Version 2.0 of REC. Some
of these include a full-screen on-line door program to allow you
to directly examine, search, and update the echo control file
while on-line while maintaining an acurate log of what you did.
The limits imposed by using static memory will be further
replaced with dynamic memory allocation, which will make REC
faster and more efficient. These will include the Address,
EchoHub, and EchoNode configuration statements.
Best of luck in you BBSing, and my thanks for using this
software. Later!
Dan Fitch
Author of Remote Echo Control (REC)
Sysop of The Rec Room
1:104/435@FidoNet
200:5000/211@MetroNet
Denver, Colorado
revised April 20, 1991.